昨天我們第一次把 LLM 放進系統。
它的工作很單純：

理解申請人寫的異常原因。

例如：

「因設備切換造成起機損耗增加。」
LLM 可以把它分類成：

CHANGEOVER

這一步很有價值，但今天要處理一個更重要的問題。

申請人說有設備切換，就真的有設備切換嗎？

如果答案是「不知道」，那我們就還不能進入真正的審核。

理解文字，不等於知道事實

這是我覺得很容易混在一起的一件事。
LLM 很會理解一句話。
例如：

「換線後重新開機產生較多廢料。」
它可以知道這是在描述：
換線 / 設備切換。

但它並不知道：

那一天到底有沒有真的換線。
這是兩個不同層次。
第一個是：
Semantic Understanding，語意理解。
第二個是：
Fact Verification，事實驗證。
審核系統如果只做到第一層，其實還不夠。

還是回到我們的案例

假設申請人填寫：

因設備切換，起機過程產生額外損耗。
LLM 判斷：

Category = CHANGEOVER

接下來，我們應該去查什麼？
至少可以查：

• MES 生產紀錄
• 設備事件紀錄
• 換線紀錄
• 工單時間
• 停機紀錄

例如系統查到：

工單：WO-20260918001
生產開始：08:10
設備切換：08:03
重新開機：08:08

這時候我們可以說：

申請人說「有設備切換」，系統資料也有對應紀錄。

這叫：
Claim Supported。

但如果查不到呢？

另外一種情況：
申請人說：

因設備切換造成損耗。

但 MES 查到：

生產開始：08:10
設備切換：無
停機事件：無

那系統就應該標記：

Claim：有設備切換
System Record：查無對應紀錄
Result：CONFLICT

這時候很重要的一件事是：

不要急著讓 AI 幫忙圓回來。
它不應該說：
可能是人工漏登。
也不應該說：
有可能設備切換沒有被系統記錄。
因為這些都還只是推測。

真正好的審核系統，應該老實地說：

目前資料有衝突。

這就是審核和聊天最大的不同

聊天可以合理推論。
但審核不能只靠合理。
因為企業真正要的是：

可驗證。
所以今天開始，我們要建立一個很重要的概念：
Claim vs Evidence

Claim 是申請人說的話。
Evidence 是系統可以驗證的資料。

例如：

Claim：
設備切換造成起機損耗
Evidence：
MES Event ID EVT-20260918-003
08:03 發生設備切換

這時候兩者一致。
但如果查不到 Evidence，
系統就不應該直接接受 Claim。

我會把查證結果先分成三種

為了讓後面的系統更容易處理，可以先做簡單分類：

SUPPORTED
CONFLICT
NOT_FOUND

意思如下：

這三種狀態很好用。
因為後面可以直接接 Rule Engine。

例如：

IF verification = SUPPORTED
→ 繼續審核

IF verification = CONFLICT
→ HUMAN_REVIEW

IF verification = NOT_FOUND
→ 補件或人工確認

這樣就不需要什麼事情都叫 LLM 自己決定。

今天的架構可以再往前一步

昨天的流程是：

Request
   ↓
Data Validation
   ↓
Rule Engine
   ↓
LLM Text Classification
   ↓
Risk Level
   ↓
Human Review

今天多加一層：

Request
   ↓
Data Validation
   ↓
Rule Engine
   ↓
LLM Text Classification
   ↓
System Data Lookup
   ↓
Claim Verification
   ↓
Risk Level
   ↓
Human Review

可以看到，AI 並沒有一直變大。
反而是系統周邊開始變完整。

這也是企業 AI 很現實的一面

很多人談 Agent 的時候，會把重點放在：

• Prompt
• Model
• Tool Calling
• RAG

但真的進企業之後，很多時間其實花在：

怎麼把正確的資料找出來。

因為如果輸入資料就是錯的，模型再強都沒有用。

例如：

錯的工單號
+
錯的設備紀錄
+
錯的 SOP 版本

最後得到的 AI 分析，即使文字寫得再漂亮，也沒有價值。
所以我會把這句話記下來：

審核型 AI 的品質，很多時候不是由模型決定，而是由 Evidence 品質決定。

那今天需要 LLM 做什麼？

其實不多。
它只要幫忙把申請文字轉成「要查什麼」。
例如：
輸入：

因設備切換造成起機損耗。

LLM 可以產生：

{
  "claim_type": "CHANGEOVER",
  "required_checks": [
    "設備切換紀錄",
    "生產時間",
    "重新開機紀錄"
  ]
}

接著真正查資料的工作，交給系統。
也就是：

LLM 負責理解，Tool 負責查證。
這個分工我覺得非常重要。

不要讓模型自己幻想資料

這裡也要特別提醒一件事。
如果 AI 說：

根據 MES 紀錄，當天確實有設備切換。
那這句話一定要真的來自 MES。
不能只是因為 Prompt 裡提到「設備切換」，模型就順著講下去。
所以後面我們會慢慢建立：

Source
Timestamp
Record ID

例如：

Source：MES
Record ID：EVT-20260918-003
Time：08:03

讓每一個 Evidence 都可以往回查。
這就是後面 Evidence Chain 的基礎。

今天的重點

Day 5 我只想留下三件事情。
第一個：

理解一段話，不代表這段話是真的。

第二個：

審核一定要把 Claim 和 Evidence 分開。

第三個：

LLM 負責理解，系統資料負責證明。

當兩者一致，我們可以往下走。
當兩者衝突，系統就應該停下來。

明天：就算查到了資料，也不代表可以直接判斷

今天我們已經知道怎麼查：

申請人說的事情到底有沒有發生。
但下一個問題更麻煩。
就算真的有設備切換，是不是就代表：
這筆 7% 的材料差異可以接受？

不一定。
因為我們還缺一個非常重要的東西：

公司規範。

Day 6，我們會開始讓系統去找 SOP。
也會第一次真正進入：
RAG（Retrieval-Augmented Generation，檢索增強生成）。
而且我們會先處理一個很現實的問題：

找到文件，不代表找到的是對的文件。

明天見~